Closes #3103.

Takes option 2 from the issue — and it turned out to be more than "the better long-term semantics": the old rule was a false positive, contradicting a contract the rest of the framework already documents.

Why option 2, not option 1

A fresh scaffold's 4 errors are all for strings the template does author inline:

✗ Object "demo_note" label missing translation for locale "en"       # label: 'Note'
✗ Object "demo_note" pluralLabel missing translation for locale "en" # pluralLabel: 'Notes'
✗ Field demo_note.title label missing translation for locale "en"    # label: 'Title'
✗ Field demo_note.body label missing translation for locale "en"     # label: 'Body'

The inline label: is the default-locale text, and the framework says so everywhere except in the coverage rule:

• The runtime resolver falls back to it. i18n-resolver.ts translateObject: lookupObjectField(bundle, objectName, 'label', opts) ?? doc.label. Its docstring states the order: requested locale → fallbackChain → literal label from the metadata. Nothing renders broken or empty.
• os i18n extract generates bundles from it — pushEntry(..., obj.label ?? objectName, ...).

So coverage was demanding an en bundle that mechanically restates data the linter already holds, for text that renders correctly. Option 1 would have shipped that duplicate into the template and frozen the ritual for every user: the errors return the moment someone adds their own object.

It's also not only about the template. An object with a label but no pluralLabel was told its pluralLabel was "missing translation" — a demand to translate a string that doesn't exist, unfixable by authoring anything except a bundle entry.

The change

An inline label satisfies the default locale; a bundle is what other locales need. A key with no source string anywhere is no longer an i18n gap — a missing label is already required/label's finding (lint.ts:155-225).

This also removes an inconsistency rather than adding a special case: collectExpectedKeys already only expected confirmText / successMessage / description when authored. label / pluralLabel were the outliers.

Platform form fields keep their key: they omit label by design and let the renderer humanize the path (name → Name), so that derived text is a real source string other locales still owe a translation for. This mirrors the extractor's seed value — which the coverage walker's docstring already promises it does. (My own new test caught that I'd otherwise have silently dropped ~800 platform keys from non-default-locale coverage.)

Verification

The issue's repro, end to end — create-objectstack → os lint:

Before:  4 error(s)                     After:  ✓ All checks passed   (exit 0)

And against a real multi-locale project, the non-default-locale signal is preserved exactly:

Warnings are byte-identical — no real gap was dropped; only the default-locale duplicates are gone. os i18n check now reports the truth: "Non-default locales have gaps but the default locale is fully covered."

The platform baseline drops 2451 → 1634 hidden issues — a delta of exactly 817, its en third (817×3 locales → 817×2) — because the platform ships English labels inline too. That arithmetic is what confirms only the en share vanished.

Full CLI suite green: 548 tests / 52 files. Two existing tests asserted the old behaviour and were rewritten to test the real intent (a genuine default-locale gap = a string in another locale with no source text for the default one), plus 7 new tests pinning the scaffold shape, the zh-CN-first case, and the bundle-only case.

Follow-ups (not in scope)

• os lint ignores a project's declared i18n.defaultLocale and always lints against 'en' (the oclif flag's default: 'en' makes "declared" indistinguishable from "defaulted"). This change reduces the blast radius but doesn't fix it.
• Coverage skips array-form options: [{value, label}] entirely; the extractor handles both.
• The scaffold's AGENTS.md documents an src/i18n/ directory it never creates, while real examples use src/translations/.

🤖 Generated with Claude Code